Hardware logic emulation systems are known devices that implement a user's design in a plurality of programmable integrated circuits. Such logic emulation systems are available from various vendors, including Cadence Design Systems, Inc., San Jose, Calif., United States of America, and others. Typical emulation systems utilize either programmable logic chips or processor chips which are programmably interconnected. In programmable logic chip (e.g., field programmable gate array, or FPGA) based emulation systems, the logic contained in the user's design (referred to herein as the “design under verification”, or “DUV”) is programmed into the logic chip such that the logic embodied in the DUV takes actual operating form in the programmable logic devices. In processor-based emulation systems, the user's design is processed so that its functionality appears to be created in the processors by calculating the outputs of the design. The logic itself is not implemented in a processor-based emulation system, meaning that the DUV does not take actual operating form in the processors. Examples of hardware logic emulation systems using programmable logic devices can be seen in, e.g., U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191. U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips can be seen in, e.g., U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030. U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030 are incorporated herein by reference.
The DUV is usually provided in the form of a netlist description of the design. The netlist may have been derived from many sources, including from a hardware description language. A netlist description (or “netlist”, as it is referred to by those of ordinary skill in the art) is a description of the circuit's components and electrical interconnections between the components. The components include all those circuit elements necessary for implementing a logic circuit, such as combinational logic (e.g., gates) and sequential logic (e.g., flip-flops and latches). In prior art emulation systems such as those manufactured and sold by Cadence Design Systems, Inc., the netlist is compiled such that it is placed in a form that can be used by the emulation system. In an FPGA-based emulator, the DUV is compiled into a form that allows the logic gates (both sequential and combinational) to be implemented in the FPGAs. In a processor-based emulation system, the DUV is compiled into a series of statements that will be executed by the processors on the processor chips. No logic is implemented into these processors.
One of the main uses for hardware logic emulation systems is to debug the DUV so that the user's design, once fabricated in actual silicon, contains no functional errors. Circuit designers have used emulators for many years now to perform such debugging because the alternative, simulation, is much slower than emulation. Simulation is a software based approach, in which design and testbench are compiled into machine executable model and executed in workstation or PC. The testbench in an emulator is often represented as a target board, which interacts with the DUV directly.
In order to debug a DUV, the designer needs to look into activities of design signals over time. The reason for this is that digital circuits are driven by one or more clocks, and errors can occur at various transitions of the clocks driving the design, i.e., the DUV. The designer faces at least two issues when evaluating design signals over time. One issue is which signal to observe (i.e., which node in the DUV to observe). A second issue is when to observe the signals (i.e., at what clock transition and/or which confluence of events—sometimes referred to as a trigger). These two issues impose serious challenges to simulation and emulation tools. First, circuit designs are typically very large (e.g., in the order of million gates). Second, the number of signals the designer would like to observe is proportionally large. Third, since the time window in which design signals need to be observed (referred to herein as the “trace window”) is hard to predict prior to simulation or emulation, the designer who is debugging a design would prefer the trace window to be as large as possible.
In order to handle these issues, circuit designers have used various approaches. One such approach is to run the DUV lockstep in a simulator. With this approach, progress of simulation is controlled by designer in interactive operation. Designers can run simulation, stop and observe signals, continue, and repeat the process. When simulation stops, designers can check the state of any signal in the design. A second approach is to perform free running simulation with signal dump. With the “free running” approach, simulation is executed freely without user intervention, and signals to be observed during simulation are dumped out during simulation. It is important to note that the signals to be dumped out must be specified before the simulation starts. These simulation approaches, while effective, are very slow. A third approach is to emulate the DUV using an emulator that allows full visibility for a fixed size of trace window. In this approach, the emulator is running freely, and signals generated by the DUV in the emulator that allow for full vision are saved for a certain period of time. A final approach is to emulate the DUV with an emulator that provides for limited visibility and replay. With this approach, limited information is saved during emulation. Designers might need to run emulation a few times in order to get sufficient information for analysis.
The design verification industry has struggled for many years to provide visibility into DUVs. Prior art emulation systems provided some functionality in this area. Most prior art emulators provided various different methods for “probing” various nodes in the DUV so that the signals at that node were observable. For example, in U.S. Pat. No. 5,425,036 to Liu et al, a method was taught that allowed signals to be probed utilizing the “readback” function present in many FPGAs. In U.S. Pat. No. 5,777,489 to Barbier et al, the FPGA had scan chains fabricated onto the FPGA that allowed for tracing all the state elements on the FPGA. Yet another method is described in U.S. Pat. No. 5,943,490, which programmed scan chains into the FPGA to allow tracing of selected subsets of state elements. In U.S. Pat. No. 6,446,249 to Wang et al, each of the logic elements (which implement the logic in the DUV) has a corresponding probe flip-flop, which can be randomly accessed by a probe sequence memory, the contents of which are read out in probe streams.
Regardless of which method the prior art systems used for capturing the values of various signals created by the DUV, no prior system can provide any debugging facilities for those portions of the DUV that include memories. In fact, prior art emulators that even considered this problem would only treat such memories as “black-boxes”, meaning that the prior art emulators simply ignored the memories in the DUV and only allowed capture of the black-box's output signals. See, for example, U.S. Pat. No. 6,061,511 to Marantz et al (and specifically, Col. 6, Lines 21-30).
Because memories are an important part of any DUV, there is a need for a debugging method that allows an emulator to restore all the data stored in any location of the memories in the DUV. There is also a need for a debugging environment that does not require interruption or slow-down of the verification process for storing periodic snapshots.